home *** CD-ROM | disk | FTP | other *** search
/ Technotools / Technotools (Chestnut CD-ROM)(1993).ISO / unix / cforth / cforth.zoo / cforth.bugs < prev    next >
Encoding:
Text File  |  1987-04-08  |  2.2 KB  |  45 lines
  1.  4-Jun-85 01:13:25-MDT,2226;000000000001
  2. Return-Path: <unix-sources-request@BRL.ARPA>
  3. Received: from BRL-TGR.ARPA by SIMTEL20.ARPA with TCP; Tue 4 Jun 85 01:12:15-MDT
  4. Received: from usenet by TGR.BRL.ARPA id a003579; 4 Jun 85 1:41 EDT
  5. From: Guy Harris <guy@sun.uucp>
  6. Newsgroups: net.sources.bugs,net.bugs.usg
  7. Subject: Re: bugs in cforth
  8. Message-ID: <2253@sun.uucp>
  9. Date: 1 Jun 85 05:52:44 GMT
  10. Xref: seismo net.sources.bugs:373 net.bugs.usg:255
  11. To:       unix-sources-bugs@BRL-TGR.ARPA
  12.  
  13. >    Found a couple of small things while getting the code
  14. > up and running on our Pyramid:
  15. > 
  16. >  - Getblocks() wasn't recognizing the existance of
  17. >    forth.block because fopen(blockfile,"a+") didn't
  18. >    leave the pointer at the end of the file.  Fixed
  19. >    it by inserting an fseek(blockfile,0L,2) after
  20. >    the open.  This is definitely a Pyramid problem,
  21. >    but I couldn't recreate it in my own tests.
  22.  
  23. If you do an 'fopen(..., "a+")' in the "att" universe on a Pyramid (or in
  24. any other circumstance where you'd be using the System V standard I/O
  25. library), the "fopen" doesn't do an "lseek" to the end - it just sets the
  26. "forced append" bit on the underlying file descriptor, so that writes will
  27. get stuck at the end *but* reads will read from the beginning.  Moral of the
  28. story: if you want to have your code run on System V and non-System V
  29. systems (V7 and S3 didn't do the "forced append" bit, either), *only* use
  30. "a", not "a+", and only use that if you're going to append to a log file.
  31. If you want to open a file for reading and writing without truncation, use
  32. "open" and "fdopen".
  33.  
  34. Now for the S5 bug - why does it do the "lseek" when opening in "a" mode but
  35. not in "a+" mode?  The "lseek" seems semi-pointless when opening in "a"
  36. mode, since the forced-append mode guarantees that *all* writes go to the
  37. end of the file, regardless of what seeks you do; you may argue that doing
  38. the "lseek" makes an "ftell" return an offset indicating the end of the file
  39. but an "ftell" on such a stream isn't very useful anyway, since all writes
  40. have an implied seek to the end of the file?  On the other hand, doing the
  41. "lseek" when you are opening "a+" makes it work more like pre-S5 versions of
  42. the standard I/O library.
  43.  
  44.     Guy Harris
  45.